The present invention relates to the field of composite workflow systems and, more particularly, to utilizing user-defined policies to automate changes made to composite workflows.
Composite workflow tools and/or systems like RATIONAL CLEARQUEST allow organizations to define a workflow in a hierarchical structure to represent the dependencies and/or relationships between different steps. The hierarchical structure of a composite workflow provides many benefits of linear workflow, such as parallel task performance and customizable lifecycles for records at each tier in the hierarchy. However, in providing such an open structure format to accommodate a variety of workflow configurations, many composite workflow tools/systems lack flexibility in terms of performing and/or providing a structure to the way in which operations are performed upon the composite workflow.
For example, the progression of a workflow from one tier to the next requires a user to manually create the records of the next tier. In many situations, the records created for an instance of a composite workflow are of a redundant nature. That is, the user knows that, for every second tier record of a specific type like “Bug Fix”, three third tier records need to be created—“Plan”, “Develop”, and “Test”.
Further, a high volume of workflow instances and, therefore, “Bug Fix” records results in a large quantity of redundant actions performed by the user. A large quantity of redundant manual operations increases the possibility of user error during entry. The composite workflow tool/system lacks the ability for the user to automate the performance of this redundant activity.
While the hierarchical structure of a composite workflow provides relationships in a vertical direction (i.e., parent-child), it does not allow the establishment of any horizontal relationships (i.e., sibling). As such, the composite workflow tool/system allows the creation of situations that users know to be illogical.
Using the previous example, it is possible for a user to activate (i.e., place in a state of active work) the “Plan”, “Develop”, and “Test” records, when, logically, these tasks need to be performed sequentially. Thus, the test and development users receive notification that they should be performing work, when the source of their tasks is unavailable. Further, their records stay in the active state and provide inappropriate metrics for their work (i.e., the record was active for 33 days, though the user spent 25 of those days waiting for their source data).
Unfortunately, work-arounds to such problems encountered result in hard-coded solutions to the underlying schema of the composite workflow. Such attempted solutions reduce the nature of the workflow from composite back to linear. Further, a hard-coded solution compromises the flexibility of the composite workflow schema, impeding its maintenance and ability to adapt to changing business needs.